IP networks enable broadcasting of conversational data (Voice Over IP, Content Sharing, Presence, Instant Messaging, etc.).
The designation H.323 covers a set of protocols for transmission of voice, image and data over IP, as explained in the on-line encyclopedia Wikipedia. These protocols were developed by the ITU-T. They can be grouped together into three categories: signaling, codec (coder-decoder) negotiation, and information transport.
The SIP is defined by the IETF in the document RFC 3261. This protocol makes it possible to set up, modify and terminate multimedia sessions in a network using the Internet Protocol. The SIP also allows event notification procedures and sending information outside the context of a session. It is widely used for instant messaging service commands. Thus in an SIP environment there exist different types of calls such as session set-up requests and requests exchanged outside of any dialogue.
These sophisticated session control protocols make use, in particular, of signaling messages, which are messages enabling a terminal to request a connection with another terminal, and messages signaling that a telephone line is busy, or that the called telephone is ringing, or that the telephone is connected to the network and may be contacted in such or such a manner.
The invention relates particularly (but not exclusively) to IP Multimedia Subsystem (IMS) infrastructures. The IMS is defined by the standards bodies 3GPP (3rd Generation Partnership Project) and TISPAN (Telecommunications and Internet Converged Services and Protocols for Advanced Networking). It is a network architecture introduced by the 3GPP for mobile networks, and then adopted by TISPAN for fixed networks. This architecture enables dynamic setting up and control of multimedia sessions between two clients and reservation of resources at the level of the multimedia stream transport network. It also manages the interaction of services. At present the IMS allows access to telephone, videophone, presence, and instant messaging services.
When a user wishes to obtain the benefit of services offered by an IP network such as those described above, they send network signaling messages that may in particular include various types of request.
First, the user terminals must register with the network. If the network is unable to link this registration and a previous registration (for example following a network fault or the terminal being switched off for longer than a predetermined expiration period), the registration is considered as being an initial registration. After an initial registration, the user terminals must periodically (for example every hour) send the network a request to confirm that they wish to maintain their registration; the time interval between two such requests is referred to as a registration refresh period.
Moreover, if the network uses the Session Initiation Protocol, user terminals may subscribe to services by sending a corresponding request. This service may be an event notification service: for example, if the user has a voicebox on the network, their terminal may subscribe to a message posting notification service, i.e. it may request to be informed each time that a message is placed in the voicebox; the user terminal may also request to be notified of its registration status. It may equally subscribe to a presence notification service enabling it to receive information published by another user that it has designated, and so on.
Following the initial subscription request, the terminal must periodically send the network a request to renew its subscription; the time interval between two such requests is referred to as the subscription refresh period.
The various states of the terminal-network system requiring periodic refreshing are commonly referred to as soft-states. The applicable standards require the terminals to manage timers enabling them to send these refresh requests (registration or subscription refresh) automatically.
When a user is registered on the network from a terminal (whether this refers to an initial registration or a refresh), the network informs the terminal of the registration refresh period required by the network operator. This registration refresh period indicated to the terminal is less than or equal to a core network level Expires (registration duration) parameter; the document RFC 3261 referred to above specifies an Expires parameter value equal to 3600 second(s).
After being initially registered, a terminal may, as explained above, subscribe to certain services (for example a message posting notification, presence notification or registration status notification service). The initial subscription requests are sent either automatically just after initial registration or following user action via the interface of the terminal. For each subscription (initial subscription or subscription refresh), the network informs the terminal of the refresh period required by the network operator for that subscription. In the document RFC 3265, the maximum subscription refresh period used by the core network is defined with reference to the event-package part of the document defining the subscription type; for subscribing to the message posting notification service, for example, the document RFC 3842 specifies a refresh period from a few hours to a few days (see under “event-package message summary”).
In this context, during normal operation of the network, the network receives initial registration and initial subscription requests and also receives registration and subscription refresh requests as and when network users connect and then renew their registrations and their subscriptions after the provided respective refresh periods. The processing capacity of the nodes of the network is obviously intended to accommodate the corresponding request frequency, in particular as a function of the usual number of network users. In many circumstances, and in particular with so-called “always-on” networks and services, in normal operation, the reconnection rate, and thus the initial rate of registration and subscription, is particularly low. This situation is shown in FIG. 1a. 
However, particular problems arise in this situation in the event of a partial or complete fault of the network.
When a fault occurs in the network, the terminals connected to the faulty node or link all attempt to effect an initial registration followed by one or more initial subscriptions. The rate at which terminals seek to effect initial registration depends on how they are programmed. For example, the LiveBox terminals from France Telecom are at present programmed to attempt to register every four minutes. Thus the terminals apply a time-out period that is usually between a few tens of seconds and a few minutes, and much shorter than the registration refresh period, which leads to an abnormally high rate of registration attempts. In other circumstances it is an action of the user via the interface of the terminal that triggers the registration attempt.
For a given terminal, the time for which the terminal must wait after a network fault before being registered again is therefore on average an increasing function of its time-out period. The expression “on average” refers to the fact that, for a given terminal, this time also depends on the moment at which the terminal attempts to register relative to the moment at which the fault clears. If by chance it attempts to register just after the fault clears, and assuming that the network is not overloaded, it is virtually certain that it will succeed in registering; in contrast, if it attempts to register just before the fault clears, it will have to wait the entire time-out period before attempting again to register.
Thus, in the prior art, on rebooting the network, the terminals send their respective registration requests slightly offset relative to one another. During a time of the order of the average time-out period, the network must therefore accommodate an abnormally high influx of requests, in proportion to the fault duration. Moreover, assuming that the network is capable of processing this reboot traffic, it must accommodate a new influx of requests coming from the same terminals at the end of the registration refresh period. This situation is shown in FIG. 1b. 
However, the assumption to the effect that the network is capable of processing all signaling requests on a reboot often proves to be false in practice. As a function of its capacity (which may vary from one node to another), each node of the network processes the first requests that it receives; under such circumstances, the load on the nodes of the network increases rapidly until an overload is very often reached. Under these conditions, one or more nodes of the network (notably of the core network) no longer manage to satisfy all requests in time. To be more precise, for terminals for which the request has not been processed:                either these terminals receive a failure response from the network;        or these terminals receive no response in an allotted time (64.T1, i.e. 32 seconds if T1=500 milliseconds (ms) as in the document RFC 3261), and deduce from this that their registration request has failed.        
These terminals then effect successive registration attempts separated from one another by said time-out period until they finally succeed in connecting or reconnecting (or give up trying).
Thus, following a fault in known telecommunications systems, there are seen both saturation of the network and a long waiting time before a plurality of terminals are able to connect or reconnect.
Various methods of managing faults in telecommunications networks are known.
For example, a proposal known in the art defines a time-out algorithm intended to be used by a terminal that has failed on an initial registration or registration refresh attempt. Using that algorithm, the waiting time observed by the terminal depends not only on the registration refresh period but also on the number of consecutive registration failures (to be more precise, the time-out period doubles each time that the terminal suffers another failed attempt to register, provided that the registration refresh period is not exceeded).
Known fault management methods are far from the optimum:
1) the duration of the time-out period is chosen by the terminal or by the user, instead of being indicated by the network; the terminals used to access services offered by a network operator are not necessarily programmed by the operator concerned, and the operator is therefore unable to program those terminals according to its requirements;
2) there is no provision for distinguishing between the different types of requests (registration, event notification subscription, presence notification subscription, and so on); consequently, the risk of congestion is evaluated as a function of all the requests that are usually sent after a reboot; for the network operator, satisfying subscription requests has a lower priority than enabling all users who so require to be able to register.